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BACKGROUND OF THE INVENTION 



FIELD OF THE INVENTION 

The present invention relates generally to methods and systems for supporting the 
management of tasks and documents within a message-based system, and more particularly to 
methods and systems for embedding personal information management and collaborative and 
20 coordmation-related infonnation management in a message-based system 



DESCRIPTION OF RELATED ART 

Personal infonnation management can be defined as the ordering of information 
through categorization, placement, or embellishment in a manner that makes it easier to 
25 retrieve when it is needed. It may also involve information related to coordination and 
collaboration. Email is increasingly used by many users for many information management 
(IM) functions. Currently, email clients such as Microsoft Outlook™ do have features that 
support many IM functions. However, these features are not easy to use and are not well 
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integrated with email. Thus, there is a need for an email client with embedded IM features, or 
more generally, a message-based system with with embedded M features. 

There are, broadly speaking, three types of traditional workflow systems: image-based 
workflow systems, form-based workflow systems, and coordination-based workflow systems. 
S Image-based Workflow Systems are designed to automate the flow of paper-based 

documentation through an organization, by transferring the paper to digital "images". These 
were the first workflow systems that gained wide acceptance. These systems are closely 
associated with imaging technology, and emphasize the routing and processing of digital 
images. 

10 Form-based Workflow Systems are designed to inteUigenfly route forms throughout an 

organization. These forms, unlike images, are text-based and consist of editable fields. Forms 
are automatically routed according to the information entered on the fonn. In addition, these 
form-based systems can notify or remind people when action is due. 

Coordination-based Workflow Systems are designed to facilitate the completion of 



m 15 work by providing a framework for coordination of action. The framework is aimed at 
addressing the domain of human concerns (business processes), rather than the optimization 
of information or material processes. 

These three types of workflow systems all share the same requirement The 
requirement is tiiat a top-down, centralized model of the work process has to be defined. The 
20 centralized workflow model keeps track of a pre-specified set of deadlines and obligations, 
thus, does not allow for flexible workgroup performance. Therefore, there is a need for a 
workflow system that would allow for more flexible workflow management, without the need 
for multiple parties to be using a single centralized system or workflow schema. 

25 SUMMARY OF THE INVENTION 

A method for providing emergent and flexible workflow management to a user is 
disclosed. The user conmiunicates with other users, using a message-based system having 
embedded information management resources. The message-based system has a viewer. A 
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message is generated at the message-based system, The message has metadata. The metadata 
of the message is updated using the embedded information management resources. The 
metadata include at least one of the group of a deadline, a reminder, a deferral and an 
obligation. The message is sent to the other users. Some of the metadata of the message are 
5 displayed on the viewer of the message-based system. Some of the metadata of the message 
are tracked at the message-based system. 

BRIEF DESCRIPTION OF THE DRAWINGS 

10 The features and advantages of the present invention will become s^arent from the 

following detailed description of the present invention in which: 

wis 

j;3 FIG. 1 shows an illustration of embedding information management in the email client 

' 2 mechanism using the system of the present invention, called TaskMaster. 

FKj. 2 illustrates an embodiment of TaskMaster. 
i g 15 FKj. 3 illustrates another embodiment of TaskMaster. 

• " FIG. 4 shows how TaskMaster responds to the Outiook event "new mail arrived in 

^3 user's inbox". 

FIG. 5 shows how TaskMaster responds to the clock event "current minute has 
changed**, 

' ^ 20 FIG. 6 shows how TaskMaster responds to the user event *\iser clicks on a thrask". 

FIG. 7 shows how TaskMaster responds to the user event "user clicks on an item'*. 
FIG. 8 shows how TaskMaster responds to the user event *\iser hits the "change color** 
key on the keyboard. 

FIG. 9 is an exemplary appearance of an embodiment of the TaskMaster. 
25 HG. 10 shows a different design embodiment for the tiirask list pane PI which 

includes additional features. 

FIG. 1 1 shows examples of menu options available for a thrask in PL 

FIG. 12 shows enlarged and normal views of approaching deadline warning bars. 
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HG. 13 shows enlarged and nonnal views of the balls (actions) in the user's court 
(red) versus those in other people's (blue) as seen in the thrask list pane PL 

FIG. 14 shows one embodiment of the item list pane P2. 

FIG. 15 shows another embodiment of the item list pane P2. 
5 FIG. 16 is an exemplary depiction of an item template mechanism. 

FIG. 17 shows the pop-up dialog box that appears when a deadline or reminder has 
passed in the system. 

FIG. 18 shows an exemplary schematic of a workflow-enhanced architecture for 
TaskMaster. 

10 FIG. 19 shows in block diagram form a computer based system upon which the 

TaskMaster system may be implemented. 

P 

y DETAILED DESCRIPTION OF THE INVENTION 



15 For clarity purposes, some terms that will be used hereinafter are defined here. The 

term "document" is used to denote any information item that is not a message. The term 
document is meant to include links (URLs), notes, attachments to mail messages, etc. 

The term ""message"" is defined as a finite unit of communication (suitable for, but not 
limited to human-human communication; e.g., a machine may be substituted for a human) that 

20 can be sent (in one transmission action, as opposed to streamed continuously) through a 
network from a sender to one or more recipients (where the recipient may be the sender). The 
communication is usually text but may include video or audio. The communication may also 
include entire files (such as email attachments). 

The term "email client" is defined as a piece of software that recognizes and handles 

23 exchange of computer-stored messages (email messages) by telecommunication. Email is one 
of the protocols included with the Transport Control Protocol/Intemet Protocol (TCP/IP) suite 
of protocols. A popular protocol for sending e-mail is Simple Mail Transfer Protocol and a 
popular protocol for receiving it is POPS. 
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The term "message-based system" is defined as piece of software that handles or 
incorporates the transfer of messages as a core function including, but not limited to email 
messages. Such a system may use a private protocol that is not understood by email clients, 
and it may include other features beyond email such as document management and workflow 
5 resources. Thus, email clients form a subset of the set of message-based systems. 

A task is defined as an activity assigned to or taken on by someone with some criteria 
for accomplishment or progress and some goal or goals (such as balance budget). It may or 
may not have a deadline. A human task cannot be fully embodied in any system 
representation, because it is purely a matter of judgment as to what a task is. However, 
10 system items such as documents or messages can be used to stand as task representations or 
reminders in the user's mind. 

A thread is defined as a protracted activity comprising one or more tasks with some 
g thematic relationship such as similar or the same goals, or a common set of colleagues 

• L! involved, without necessarily having criteria for accomplishment since the thread may not 

Ijy 15 have a final deadline or a terrmnation state (such as the thread for tracking bw A 
^ thread cannot be fully represented by a system object or objects. However, items can be used 

to stand for threads in terms of having content largely or wholly related to a thread within a 
M single collection of items. 

n In Microsoft Outlook™, the term thread is used to refer to a series of email messages 

20 that can be related to one another using sender, recipient, subject line and message ID 
information. 

In the present invention, the new term 'thrask" is defined. Masmuch as the tenn 
thrask refers to a collection of related items in the browser of the present invention, it is like a 
Microsoft Outlook™ thread. However, a thrask is less easy to capture technically, because it 
25 does allow for an element of human judgment Thus, in the present invention, the term thrask 
encompasses much more than what is defmed for a thread in Microsoft Outlook™. The 
following are some differences between thrasks and Microsoft Outlook™ threads. 

A thrask is a cross between a task and a thread. A thrask may or may not have a single 
deadline, and may or may not include items representing multiple tasks. 
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A thrask may or may not correspond to a series of messages of the sort that can be 
computed by Outlook™ for an Outlook™ thread hi a similar way to Outlook™, in the 
system of the present invention, new items are added to the thrask automatically using sender, 
recipient, subject line and message ID information. However, by contrast with Outlook™ 
5 threads, a user can manually add items to, or remove them from a thrask. A user can also 
change the name of a thrask. 

A thrask can include not only messages (or not even any messages), but other items as 
well, since users are not confined to working only with email content. Other items can be 
documents and links that have never been embedded in an email message. They can be notes, 
10 sharing many of the properties of unsent messages in the system of the present invention. 
These items can be included into a thrask via a menu option or by drag-and-drop mto 
TaskMaster. Thrasks are fully mtegrated with email fimctionality. The system of the present 
invention brings this stream-based multi-form document collection capabiUty into a message- 
based collection viewer. 

15 Each item within a thrask can have a deadline and a reminder attached to it as it may 

correspond to a task, or include task critical information, and thus can stand for a task. 

There may be many items with deadlines or reminders inside a single thrask. The 
thrask is the online structure m the system of the present invention that stands for the relations 
between, or organizes related human tasks represented by different messages and other items. 

20 A thrask may also contam other augmentations such as indicators manipulated by the 

user to show obligations (whose court the ball is in) for a particular task, additional "stLck-on" 
notes that can be attached to items in the thrask, tools to help the user manage the thrask 
contents such as filtering for items which the user is obliged to complete as tasks, indicators 
identifying different versions of the same document withm the thrask, mdicators as to whether 

25 a task has been terminated, and so on. 

A thrask may be very different from an Outlook task, depending on how it is 
implemented in an application. Some of the differences are as follows. 
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A thrask is embedded in the email handling part of the system of the present invention, 
while an Outlook task is a separate kind of item that is typically accessed in a separate part of 
the application (the task folder) but can also be seen in Outlook's calendar view. 

A thrask can comprise many items rather than just one item like an Outlook task. A 
thrask includes incoming items, more like an Outlook thread than an Outlook task. 

Each information item in a thrask can have metadata associated with it in the system of 
the present invention. The metadata mclude message-related information such as sender, 
subject, date, priority, and task-related information such as deadline, reminder, who is 
responsible for action, which thrask (or thrasks) the item belongs to, etc. 
In certain applications of the present invention, a thrask can be implemented as a thread of 
messages only or just a single message or a single document that is augmented with 
information management features and easy access to useful associated options. For example, 
a thrask can be implemented as a thread that has some of the task-related metadata described 
herein. These data go beyond the simple mark-up of importance or follow-up marks used in 
other messaging tools to include any of; denotation, directly in the display of flow of messages 
and other items, of who has obligations, when they are due and reminder and deferral 
functions, plus access to useful options of responses directly from items having or system 
triggers based on these metadata). A thrask may also be inq)lemented as a message that has 
some task-related metadata and options in addition to ordinary message-related data as 
described in the preceding sentence. 

For simplicity and clarity, the system of the present invention is referred to as 
TaskMaster hereinafter. 

Many multi-user messaging systems, such as an e-mail system operate on a client- 
server architecture. A messaging server provides a collection and notification function for 
incoming messages (e.g., e-mail). When a message is received for a user, it is routed to the 
"mailbox*' for that user. The user access to the mailbox is through a messaging (or e-mail) 
client. The server typically resides on a network accessible computer based system. The 
client may typically reside on a personal workstation or other system locally accessible by a 
user. Altematively, messaging (or e-mail) systems may be centrally managed wherein users 



access an e-maU appUcation directly and there is no e-mail cUent. Such systems are found for 
example on the World Wide Web (e.g., the Hotmail appUcation). It would be ^parent to one 
of skill in the art that the TaskMaster system could be implemented on any type of e-mail 
system other than the one described. Such implementations would not depart from the spirit 
and scope of the TaskMaster system described herein. 

FIG. 1 shows an illustration of embeddmg information management in the messaging 
mechanism using TaskMaster. Referring to FIG. 1, the TaskMaster user 102 runs TaskMaster 
as the sole message-based system. TaskMaster user 102 can send messages to non- 
TaskMaster using recipient 104 who sees the messages as normal. TaskMaster, as an 
integrated solution, runs as a message-based system but with information management 
capabilities embedded directly in the message handlmg part of the system. 

Another embodiment of TaskMaster can run as an additional email client on a user 
system. The user would have two email cUents, the TaskMaster and an existing email cUent 
such as Microsoft Outlook™, Eudora™, but would need to run only TaskMaster (the use of 
the name of the mail application Oudook will be understood hereinafter to stand for any mail 
client with similar capabilities). TaskMaster mirrors Outlook content while adding advanced 
support for task and information management. TaskMaster can import old messages from 
Outiook, but once installed, TaskMaster keeps on updatmg its content from Outlook's 
incoming messages. However, items that are deleted from one mail client remain in the other, 
unless they are also deleted there. Non-TaskMaster recipients of mail from a TaskMaster user 
would see email as normal. This embodiment would probably gain more acceptance from 
users than the embodiment where TaskMaster is the integrated solution, since most users 
would likely be reluctant to switch to a new message-based system even if the new message- 
based system has more capabilities. For this reason, this embodiment of TaskMaster will be 
described in detail. However, this is not to be construed as a limitation of the present 
invention. 

FIG. 2 illustrates an embodiment of TaskMaster. The embodiment 200 of the 
TaskMaster includes a thrask generating module 202, a sortmg module 204, a display module 
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206, and further includes an updating module 208. In one implementation, the message 
viewer has three viewing panes. 

The thrask generating module 202 generates a set of thrasks (e.g., by reference to a set 
of archived data in TaskMaster's database). Each of the thrasks includes at least one 
information item. Each of the information items can have metadata that may be identical to 
metadata of a task, such as a deadline or reminder, or the thrask metadata may be an aggregate 
of, or an abstraction from the metadata of the items it contains. 

The sorting module 204 receives (by automatic or user selection) and sorts a new 
information item into one of the thrasks in accordance with certain criteria or accepts an item 
from the users' existing items in their computer filing system or messaging system into a new 
thrask by user action. 

The display module 206 causes display, in the first viewing pane, of some of the 
thrasks, and in the second viewing pane a list of the information items of a single thrask 
selected from the displayed thrasks, and in the third viewing pane some of the content of an 
information item selected from the list of the displayed information items. For each of the 
displayed mformation items in the second viewing pane, respective metadata may be 
displayed. 

The updatmg module 208 updates the thrasks. This includes updating the list of 
thrasks, the list of items in each of the thrasks, and the metadata of the information items in 
each of the thrasks. 

FIG. 3 illustrates another embodiment of TaskMaster. The embodiment 300 of 
TaskMaster mcludes a mail handling module 306, a thrask list module 308, an item list 
module 310, and a notification module 312. The system 300 further includes a form module 
302 and a database module 304. Optionally, the sjratem also includes a content preview 
module 314. 

The form module 302 manages the set of forms that are needed by the system 300. A 
form is a window that is visible to the user. For example, the main window of the TaskMaster 
is a form. The form module 302 handles the initialization of the main window, hi one 
embodiment, the main window has three viewing panes. The form module 302 does not 



generally handle the specific details of the three viewing panes, as each of the viewing panes 
is handled by its respective module, as will be described later. 

The form module 302 also contains logic to handle the compose form which allows 
the user to write, save, and send a new message. It is noted that there may be many compose 
5 windows visible at the same time on the screen, but they are all instances of the same compose 
form. 

The form module 302 also manages the item form that allows the user to see all the 
details of an item in the item's own pane within the main wmdow of TaskMaster. Message 
items can be opened in a separate window (e.g., by double clicking the items in the item list 
10 view in P2; the second viewing pane, in Fia 9) within TaskMaster, but non-message items 
will be opened in their own native application window if the user selects them to do so (e.g. 
|;3 by double clicking on them in P2), 

:|: Th^ database module 304 provides a convenient way to access the relational database 

! LJ that holds the data of the TaskMaster. The database module 304 has no effects that are visible 

l!0 15 to the user. 

The maU haadling module 306 coordinates with an email client that also resides on the 
I J user system, such as Microsoft Outlook™. The mail handling module 306 receives an event 
i;= from Outlook that a new mail item has been received. The mail handling module 306 then 

13 imports the new mail item into TaskMaster. After importing the new mail item, the mail 
■ 20 handling module 306 informs the notification module 312, which then makes decisions about 
which other modules need to be informed of the presence of the new message and any other 
information items that are produced from the importing process of Ae new mail item. 

The process of importing an item from Outlook into TaskMaster has two phases, first 
the incorporation phase, then the "thrasking" phase, hi the incorporation phase, the contents 
25 of the new mail item are copied and appropriate database tables are updated. In TaskMaster, 
links, i.e., URLs, in the text of the mail message and attachments may be considered as first 
class citizens, diat is, on the same level as the mail message. Thus, the mail handling module 
306 may create several mformation items from a single mail item during the mcoiporation 
phase. In the thrasking phase, the information items produced from the incorporation phase 
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must be put into appropriate thrasks. In one embodiment of the mail handling module 306, 
the mail handling module 306 searches for a previous message that has been placed in a thrask 
to which the new message with any associated mformation items is a response. If such a 
message is found, the new message and any associated information are placed in the same 
thrask by updating the appropriate database tables. If no such message is found, the message 
and its associated items are placed in a default thrask called 'Tending Items" thrask. After the 
thrasking phase is complete, the maU handling module 306 informs the notification module 
312 of the presence of the new information items. The notification module 312 then 
coordinates with other modules to update the screen for the user. 

The thrask list module 308 controls the display of and user interaction with the thrask 
list in a screen area referred to as the first viewing pane (or PI). The thrask Ust contains aU or 
some of the thrasks in the system. The thrask list must be updated m response to user actions, 
even when the user actions occur on the second viewing pane (P2) which displays an item list 
of a selected thrask. 

The thrask list module 308 also aggregates or abstracts from the display representation 
of certain information of all information items in a thrask. The aggregate or abstraction is a 
composite representation of that certain information about the thrask as a whole. For 
exanq)le, if a given thrask has ten information items and each of the ten has a '*ball" 
representmg an obUgation, as can be seen in the second viewing pane, the thrask list module 
308 aggregates the ten balls together and draws a smaU display of the aggregate in the first 
viewing pane in the proximity of the thrask in question. 

The item list module 310 manages a screen area referred to as the second viewing pane 
(P2). The item list module 310 controls the display of and user interaction with the list of 
information items visible to the user within a selected thrask. For example, if a thrask has one 
message, one link, and two other documents in it, the item list module 310 manages the (in 
one embodiment) four elements of the second viewing pane that represent these four items. 
The elements may be graphically represented in any number of ways; e.g., row elements in a 
list (FIG. 14), or icon elements in a groiq), or a pop-up menu view of a list, or a separate list to 
one side (such as thrask resources in FIG. 15). 
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The notification module 312 is the center of coordination within TaskMaster. The 
notification module 312 receives notifications of logical events that have occurred in the 
system and coordinates the system response, usually dirough other modules. These logical 
events are not trivial events, such as a "mouse has moved" event, but important events 
representing a change in status of mail, other items, or metadata (including temporal teiggers) 
handled by TaskMaster such as a "new mail has arrived" event. For exsaaple, if a tiirask is 
selected by the user in the first viewing pane PI, the thrask list module 308 can act to 
highlight a new thrask, update appropriate parts of PI, etc., then the thrask list module 308 
calls the notification module with the event "new thrask selected". At this point, the 
responsibility of the thrask list module 308 with respect to this event is completed. The 
notification module 312 then coordinates with the item list module 310 to put the appropriate 
new thrask content in the second viewing pane P2 for the thrask tiiat is now selected in PI, 
and to select an item in P2 so that the user has a selected item for action. 

The content preview module 314 manages the screen area referred to as the third 
viewing pane P3. When a message is selected in P2, the content preview module 314 displays 
the text of the selected message then informs the notification module 312 that the message 
should now be marked as "read" (or "seen"). The content preview module 314 also includes 
logic to display other types of information items such as the contents of links (URLs) and 
other types of documents, or an error message if the content cannot be displayed. 

The sjretem, TaskMaster, is event-driven. It acts only in response to events from one 
of three sources. The primary source is the user. A user action such as pressing a mouse 
button with the pointer over a button on the screen is considered an "event" that must be 
responded to by TaskMaster. The second source of events is Outlook, such as when Outlook 
notifies TaskMaster that new mail has arrived. The third source of events is a clock, such as 
when the day chants and the system must update displays based on the new current date. 
These clock events are periodic, but they are handled similarly to the other two types. 

FIGs. 4 through 8 illustrate how TaskMaster responds to some particular events. 
These illustrations have been sin^lified for clarity. In practice, TaskMaster responds to 
dozens of events and these events are generally at a much lower level. 
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FIG. 4 shows how TaskMaster responds to the Outlook event "new maU arrived in 
user's inbox". TaskMaster receives the Outlook event and copies the new mail message into 
the system (block 402), then checks whether the new message is a response to a previous 
message that is in a thrask (block 404). If it is, then TaskMaster assigns the new message to 
the same thrask as the previous message (block 406). If it is not, TaskMaster assigns the new 
message to a default thrask called 'Tending Hems" thrask (block 408). If the assigned thrask 
is being viewed by the user, then TaskMaster updates the item list display (P2) to include the 
new message (block 410) and updates the thrask to indicate that a new item has been received 
within it (block 412). Otherwise, TaskMaster only updates the thrask (block 412). 

FIG. 5 shows how TaskMaster responds to the clock event "current minute has 
changed". TaskMaster receives the clock event (block 502). TaskMaster checks to see if 
there arc any items in the system that have reminders set to go off at this minute (or at any 
prior minute, e.g., when the application starts up after some mterval) and which arc not 
marked "fired" (block 504). If there is none TaskMaster exits. If there are such items, 
TaskMaster picks the first item that meets the criteria (block 508), displays a dialog box with 
the reminder information to the user (block 510), marks that item as "fired" (block 512) then 
goes back to block 504 to check if there arc any other such items. 

FIG. 6 shows how TaskMaster responds to the user event '"user clicks on a thrask". 
TaskMaster receives the user vent (block 602). If this thrask is aheady selected, TaskMaster 
exits (block 604). If the thrask is not akeady selected, TaskMaster finds all items that are 
marked as members of the thrask (block 606), fills the item list pane P2 with these items 
(block 608), selects the newest item in P2 (block 610) and simulates the event of user clicking 
on the newest item (block 612). 

FIG. 7 shows how TaskMaster responds to the user event "user clicks on an item". 
TaskMaster receives the user evait (block 702). TaskMaster checks to see if TaskMaster can 
generate a preview of this item type (message, link or other document) (block 704). If no, 
TaskMaster displays an error message in the content preview pane P3 (block 706) then goes to 
block 710. If yes, TaskMastCT generates a preview of the item and display it in Ae content 
preview pane P3 (block 708). TaskMaster checks whether this item has been read before by 
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the user (block 710), If it has been read before, then TaskMaster exits (block 716). 
Otherwise, TaskMaster updates item display in P2 to reflect that this item has been read 
(block 712), then updates the thrask list displayed in PI to reflect how many unread items are 
now present (block 714), then exits (block 716). 
5 FIG, 8 shows how TaskMaster responds to the user event **user hits the **change color** 

key on the keyboard TaskMaster receives the user event (block 802). If there is no item 
currently selected in the item list pane P2, TaskMaster exits (block 804). If there is a currently 
selected item, TaskMaster determines the current color of the item's display (block 806), then 
computes the next color in the color sequence (block 808), then updates the display of item in 
10 the item list pane P2 (block 810). TaskMaster also notes the change of color for the selected 
item in the database so that this new color will be seen when this item is displayed again later, 
p TaskMaster then exits (block 804). 

p FIG. 9 is an exemplary ^>pearance of an embodiment of TaskMaster. Jn this 

I M embodiment, the TaskMaster viewer includes three viewing panes PI, P2, P3. The thrask list 

rg 15 is displayed in PL The items within the currently selected thrask "Pending Items" (mail 

Hi 

messages, notes, phone call records, documents and Imks) are shown in P2. The content of 
P the selected item having as subject *1iousing** is displayed in the content preview pane P3. 

The thrask list pane (PI) of TaskMaster is where Alice, the canonical TaskMaster user, 
can see all of the thrasks that she is tracking. Each thrask contains a list of filtered incoming 
\ ^ 20 email, documents (as attachments or otherwise included), links, notes and so on. 

FIG, 10 shows a different design embodiment for the thrask list pane PI which 
includes additional features. 

Column 1 (counting from left to right) of pane PI shows whether there are unopened 
messages in a thrask. The blue square means all items have been opened, and the black 
25 square means there is one or more that has not been opened. 

Column 2 of pane 1 with header *Title" shows the titles of the thrasks. In an 
exemplary implementation, thrasks are ordered by Title alphabetically by default, but users 
can drag a thrask to the top of the list (before the first thrask) where it is pinned in order of 
where it is placed (as long as it is above the first alphabetically sorted item). Pinning is drag 
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operation that causes a pin icon to appear showing the thrask is fixed in place; the pin can be 
clicked to un-pin the thrask fix)m its position at the top of the list. 

Column 2 of pane PI also shows the Options. An "arrow tip" symbol indicates that 
there are useful options associated with a thrask. The useful options are accessible from a 
5 pop-up widget such as a menu by clicking the arrow tip symbol. 

Column 3 of pane PI, havmg header "Due", gives warnings, for example, of upcoming 
deadlines, reminders and thrask expiry. 

Colunm 4 of pane PI, having header "Balls", indicates whether there are individual 
items within the thrask where there is some outstanding obligation. Whose court the ball is in 
10 is indicated by the color (red for my obligation, blue for others' obligations). 

Column 5, having header "Most Recent Sender", shows the sender of the most recent 
item diat arrived in the thrask (either by automatic TaskMaster filtering or by user action, e.g., 
the user can drag items from P2 to thrasks in PI). Note that if the user has included an item 
into a thrask that was not sent in email, either via a menu option or by drag-and-drop into P2, 
15 then no sender would be displayed in that item's cell in this column. 

Column 6, having header "Date" shows the date the most recent item was added to the 
thrask (widening this column by dragging the colunm bar would also display the time). 

Column 7 having header "Notes" shows handy notes of which the first few words are 
visible in PI as a reminder. The notes can be opened by clicking on them. 
20 The bar on the right, in colunm 8, is a special scroUbar. More discussion about this 

scrollbar will be provided later. 

The fu-st thrask shown in PI is the default thrask "Incoming New Hems" (also called 
"Pendmg Items" as shown in HG. 9). TaskMaster puts all new incoming items that are not 
automatically filtered into other thrasks into this default thrask. In this way, the default thrask 
25 resembles a traditional email cUent's inbox. By selectmg this default thrask, user Alice can 
view items in the item list pane P2, which she can manually add to existing thrasks, or 
otherwise process and delete. 

hi another embodiment of TaskMaster, the Pending Items thrask might look like a 
typical mail cUent's in-box, such as that of Outlook. Thus, items in this list might also be aU 
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incoming content (unless deleted or filed elsewhere) with some items duplicated (rather than 
moved) into thrasks, for example, by the mail handling module 306 described in FIG. 3. 

FIG. 11 shows examples of a menu of useful options available for a thrask in PI under 
the heading "Options." The exemplary thrask as shown in HG. 11 is entitled "End of the 
Rainbow". In FIG. 11, the currently selected item "Items due action" takes the user, via 
cascading sub-menus to a message item with multiple recipients (Toto Fido; Wanda Witch... 
etc.) to edit metadata such as deadlines, remmders, action balls, etc., by selecting "Change 
item status." The user might also select a template reply, or a new message template and so 
on. Other useful options are listed in the figure, but this collection is merely meant to 
suggestively illustrate the kmds of usefiil task-oriented information management and action 
options that one might wish to assodate closely with a thrask. 

Users may wish to have an overview of the location of certain content. The scrollbar 
in the rightmost column of the thrask Ust pane PI (FIG. 10) can be used as a kind of overview 
list viewer highlighting where to look for, say, new information (though it could be for 
important information or the results of a search, and it could be toggled to show different 
things highlighted in different states; e.g., a blue background when it is highUghting the 
location of unread items, and a pink background when it is highlighting the location of 
inq)ortant messages; etc). The scrollbar represents everything within the entire length of the 
Ust and the location of the new content relative to the length of the Ust is indicated by black 
bars. As the Ust gets longer, the lines will get narrower and gray may need to be used for 
single important items with black only being used to represent clumps of important items. 
The nature of one embodiment of TaskMaster, with items timing out automatically, means 
that this list should never get too long for this graphic to work effectively. 

This representation does not have to be in a scroUbar. It could be an additional viewer 
with no control impUcations. However, the scroUbar is a more efficient blend of utility, la 
FIG. 10, the overview scroUbar is on the right, showing the sUder in red at the very top, which 
encompasses the currentiy viewed part of the thrask Ust with two new items in it. Wider bars 
represent clunq)s of new, unread or important items. 
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In one implementation of the TaskMaster system, upcoming due deadlines, reminders 
and automatic removal of a thrask from the system are indicated to the user in the "Dae" 
column of PI (HG. 10). By thiask removal it is meant that if a thrask is unused for a while, 
for example, it, and all its items might eventually 'expire' and be removed from the display 
capabilities of PI, P2 and P3. This would most likely be after the last deadline in the thrask 
has expired. 

In one inq>lementation, to the left (right in FIG, 10) of each item's subject line in the 
thrask list, three horizontal bars of about 3-6 pixels in height and about 10-60 pixels in length 
which represent perhaps a span of two-weeks into the future each are displayed. As the 
nearest deadUne or reminder associated with one of the items in the thrask, or the thrask's 
entire removal approaches, the bars change color at one end from white to some color and the 
color change progresses along the bar untU it has conq)letely changed color and the 
deadline/reminder/removal occurs. Once this date passes, or the user changes the settings in 
the relevant thrask items, the bars wiU reset to reflect the recalculated nearest deadlines or 
reminders upcoming or the reset removal date. Users would be able to sort by these properties 
by clicking on the top of the column to toggle between which property to use to order the 
content of the thrask list. 

FIG. 12 shows enlarged and normal views of warning bars. These three bars could be 
displayed to the right of each thrask name in the thrask Hst pane PI (HG. 10), to show the 
nearest upcoming deadline and reminder and imminent removal from TaskMaster's store of 
thrasks. Here the upcoming deadline is shown as daric blue at the top, the reminder is shown 
as medium blue in the middle, and the impending removal is shown as light blue at the 
bottom. This warning bars display is an abstraction of the items of the thrask, since the 
system only indicates the "nearest upcoming" deadline or remmder with one of the bars, other 
deadlines and reminders associated with other items in the dirask are not visible in this 
embodunent. However, an alternative embodiment could show more deadUnes and reminders 
than only die nearest, or indicate upcoming deadhnes only and not reminders. 

Users need to keep track of obhgations that they must fiilfill and that others owe to 
them. In one implementation, in P3, and in another in^lementation in P2, there is a button 
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that a user can press on selected items such as documents or messages inside Iheir thrasks to 
toggle from a null default to rq)resent whose court the ball is currently in (an obligation 
represented by a red ball for my action or a blue ball for someone else's action). This results 
in the item being displayed where it is listed, either in P2 or as the most recently sent item in 
PI with an appropriately colored ball. In PI an aggregate display of these actions; a literal 
display of "balls" appearing from top left to right, line by line, that builds up to some limit for 
each thrask can be shown. The balls in the aggregate are very small, just a 2-3 pixels in 
diameter. The user's color perception will be adequate to detect the balls, and an effect of 
cumulative obUgations building up with balls being added can be achieved. Again, a user 
would be able to sort the thrasks in the thrask list by one of these properties by clicking on the 
top of the column "Balls" and selecting the property. The user may also click on the 
aggregate display of the balls themselves in the Due column in PI at the thrask level to see a 
list of the names of people associated with each action ball and useful menu options (similar 
to those shown in FIG. 1 1) such as view their last message on this action, or reply to their last 
message. 

The user may assign actions to an item in P2 (FIG. 14) without even opening it by 
clicking on a button on the same line as the item in the list view in pane P2 to toggle from the 
default "no action" state to "my action" and then to "other's action." 

Referring to FIG. 11, multiple message sender/recipients may be associated with an 
action ball, since the action is attached to the message item not to the individual sender or 
recipient. The user's own name may never need to be included as all her email has her name 
on it as a sender or recipient. Some messages have multiple people as recipients, so which 
one is actually due for an action cannot be specified. However, the user will most likely be 
able to retrieve enough context information from the message to figure this out quite easily. 
However, an advanced embodiment of TaskMaster may offer a means to assign an individual, 
identified by their email address with a specific action ball (e.g., via a menu accessible from 
clicking on their email address) and may allow multiple action balls to be assigned to a single 
item. 
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ft is noted that in FIG. 1 1, action balls can be associated with documents or other items 
other than messages. Since there is no recipient/sender list, the name of the document (e.g., 
MeetingMinutes.doc) is included in the options menu shown. An advanced embodiment of 
TaskMaster wHl allow the user to associate a name and email address with the non-message 
item, in this case the name will be represented. 

FIG. 13 shows enlarged and normal views of the obligation indicators for balls in the 
user's court (red) versus those in other people's (blue) as seen in the thrask list pane PI. In 
FIG. 13, there are eight red balls and seven blue balls. The main interest for the user is things 
that need to be done (balls building up as a visual gestalt). The secondary interest is how 
many must she do versus how much following up with others does she need to do? (the main 
color of the collection of balls gives the user a sense of whether it is herself or other people 
that have the obligations). These balls are shown to the right of each pending item's subject 
line in PI. 

FIGs. 14 and 15 show two embodiments of the item list pane P2. When a user clicks 
15 on a thrask in PI, the display in P2 is updated to show the items in the selected thrask and 
related information. 

Referring to HG. 14, colunm 1410 with the "question mark" icon header shows what 
kind of item is Usted. A mail message is indicated by a 'letter" icon 1401, a phone caU by a 
"telephone" icon 1402, a note by a **note" icon 1403, a document by a "document" icon 1404, 
^20 and a web link by a ' Veb" icon 1405. 

Column 1420 is the related documents column. This column shows which messages 
have attachments and which items are or have been attached to enclosing messages. CUcking 
on the "this is a related or an attached or enclosed document or link" icon 1421 (two 
rectangular shapes overlayed) and 'this message has attachments" (paperclips) icons in 
25 column 1420 retrieves related items (e.g., enclosing messages or other versions of the same 
document) and attachments respectively. This is needed because the user may have deleted or 
moved die related document or enclosure in TaskMaster. If the user has deleted a related item 
from TaskMaster and Oudook altogether making it unretrievable, the icon is greyed, as shown 
for the second item from the top. CUcking on the 'Versions" icon (two curved arrows in a 
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circular formation; which only appears next to documents) retrieves previous versions of the 
same document (in FIG. 14, the second item from the top is a version, but the grayed 
document item indicates that related versions have been irretrievably deleted). 

Column 3 of P2, having header "Sender", shows the sender of the item. If the sender is 
oneself, the name is shown in gray, as it is not important information, a is noted that Alice 
can either send items to herself through emailing them (in which case they appear in Outlook 
too), or else she can save items in TaskMaster only, making these items the only copy. If they 
have not been archived in Outlook, items appear in red (like the fourth item from the top). If 
Alice tries to delete such an item, she is warned she is about to delete the only copy and is 
given the chance to archive it in Outlook as a message or an attachment 

Colunm 4, having header "Subject", shows the subject line of the message. However 
in TaskMaster, the user can edit this to be more meanmgful than typical subject lines often 
are. 

The header "Options", also in column 5, indicates that there are options associated 
with messages by clicking on the "arrowhead" icon. 

Column 5, having header "Arrived" indicates the dates and times that items arrived in 
TaskMaster. 

Colunm 6, having header "Due", mdicates that there is a deadline (clock icon) and or a 
reminder (bell icon) associated with an item (every item can have neither, either or both of 
these set by the user by opening the item itself or by interacting with buttons in the content 
preview pane P3). If Alice cUcks on the clock icon, she will see the deadline. If she clicks on 
the bell icon, she will see the reminder date. 

Column 7 indicates whose court the ball is in (whose obUgation it is) on this particular 
item. Clicking m this column wiU toggle the state of the action ball from none (white) to mme 
(red) to someone else's (blue) and back to none. 

Column 8, havmg header "SUcky Notes" is for holding handy notes. TaskMaster 
provides a mechanism that allows the user to attach a handy note to an item (which can also 
be a note), the first few words of which can be read from P2. Opening an item with a shcky 
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note shows the note in the item's window. The note sUdes over the contents (hence the term 
slicky, because they seem to slide) if they are scrolled, to remain visible at all times. 

FIG. 15 shows another embodiment where documents and links are associated with, 
rather than included in the list of TaskMaster items. Here a calendar is also embodied in the 
thrask as an additional resource. The resources associated with the thrask are separated out 
from the TaskMaster items, but are visible while viewing the messages in the thrask. These 
'Thrask Resources" and "Calendar" might be displayed as lists, coUections of icons, or as a 
pop-up display(s) only in various embodiments of the invention. 

As some thrasks or individual items relate to things that are not due to become active 
for months, such as preparations for an upcoming conference after an initial email notice 
about the conference, users can defer them. Assume AUce gets a notification in March for a 
conference taking place in October. She can create a thrask from this item by dragging it mto 
PI from P2. She can then click on the Options menu and choose "Defer" (FIG. 1 1). Defer is 
a separate timed property from deadline, reminder or thrask expiry date. A dialog box will 
open aUowing AUce to pick a date for this thrask to come back into PI (with some suitable 
highUghting). Should another message arrive in this thrask in the interim, the thrask will 
re^jpear, but it can be deferred once more in the same manner. A similar set of behaviors 
could be applied to individual items within a thrask or in the "Incoming New Bems" default 
thrask (FIG. 10) such as messages, documents, notes and so on. 

Phone messages are conceptually different for users so a special kind of property can 
be defined for a note in TaskMaster to indicate that it refers to a phone call or voicemail. 
Information on whether the call is incoming or outgoing can also be included. 

A single cUck versus a double cUck on different specific parts of a thrask listing in PI 
could reveal different views of the thrask, or "Incoming New Bems" collection content, for 
example, the single cUck function in the left-most area may be assigned to toggle P2 between 
being displayed as shown in FIG. 14 or FIG. 15. A double click may be associated with 
displaying only items with deadUnes in the order in which they will arrive. Alternatively, 
double clicking could be associated with displaying deferred items, which are normaUy 
hidden. 
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It is desirable that the user be able to associate date and time and title and location with 
an item and have it be passed to Microsoft Outlook's calendar. In FIG. 15, an alternative 
solution is shown, which is to have a special calendar inside each thrask where calendar- 
related items can be moved or copied and inspected via a date-based viewer. This viewer 
S could stand in relation to Outlook's calendar in the same way that TaskMaster stands in 
relation to Outlook's message folders, mirroring calendar entries created in either Outlook or 
TaskMaster. 

It is also desirable that the user be able to add a message to Outlook contacts and have 
the right thing happen (i.e., new contact(s) for the sender and/or recipient(s) other than this 
10 instance of TaskMaster's user are created). An alternative solution would be to have a contact 
list for each thrask and a master contact list that would contain all contacts across all thrasks, 
and or contacts not associated with any particular thrasks (once again, these might mirror 
Outlook's own contact list feature). 

r 

^ Users will sometimes get a reminder from TaskMaster regarding an item that happens 

Q 15 to have an obligation (action ball) for someone else (represented as a blue ball) associated 
with it. In this case, the reminder dialog box should include a button for the user to click to 
generate a message to that person containing the body of the message with the action ball 
associated with it 

The user never has to open any item in TaskMaster to deal with it because the item list 
20 pane P3 will have buttons for all individual item-related functions at the top. However, 
should users wish to open items, only email messages, which are displayed by TaskMaster 
may still have these functions as buttons. Other items may be opened by Microsoft Office 
applications such as Word, PowerPoint and Excel. However, in an advanced embodiment of 
Tasl^aster, all productivity applications' documents can be opened within TaskMaster and 
25 maintain their function buttons and metadata state records, which would be tracked by 
TaskMaster. 

Iq another embodiment of TaskMaster the Incoming New Items thrask may behave 
very like an email client inbox, as in Outlook, with all incoming content listed there, unless 
moved or deleted (usually, modem mail clients have something equivalent to PI and P3). 
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When the user clicks on an item that has been thrasked, P2 would ^pear between (or in some 
other configuration such as a side bar or separate window) PI and P3 and the system would 
behave as described above. 

TaskMaster can be made to recognize meta-infonnation inside documents through a 
template mechanism. Conunands or instructions may be contained in a Word ffle, an Internet 
shortcut file, text file, .csv file, or any other type of file which can be configured to provide 
information to the technology that a desired computation or function is to be performed. 

Such information is customized for the TaskMaster client, (or possibly for a central 
server as shown in HG. 18) to interpret and act upon. Thus, there can be different kinds of 
notes that TaskMaster would recognize, such as: phone notes, with a phone icon; agendas, 
with a Ust of people to copy them to; or contacts that might be automatically organized into a 
special contacts-thrask. 

FIG. 16 is an exenq)lary depiction of the template mechanism. Templates normally 
exist as icons or shortcuts on the desktop or in a folder. The user may cUck on such a shortcut 
and then create a copy to fill in. The user drags this to TaskMaster where it is displayed 
appropriately according to its template type and how it has been fiUed in. Other computation 
may be possible based on template type, or the manner in which fields are filled in, e.g., "copy 
to [name]" (wtere the user fills in a name between the square brackets). 

hi TaskMaster, action balls are used to represent when someone must pursue an action. 
When an action deadlme or reminder comes due, it is quite likely that the user will want to 
follow up by communicating in some way with someone about the TaskMaster item to which 
the action is bound; or the user may want to deal with the item in some way that the system 
can anticipate. Thus, when a deadline or reminder is passed in the system, it should trigger a 
pop-up dialog box as shown in FIG. 17. 

hi FIG. 17, the pop-up dialog box shows that an action for someone else is due. There 
are some possible useful response options available to the user when an action item for 
someone else passes a reminder date or a deadline, hi this case, the deadUne has arrived, and 
the user can dismiss the dialog box by cUcking the OK button, open the item itself to consult 
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it, or choose an item from the Respond menu. These are just some examples of the kinds of 
useful response options that TaskMaster may offer. 

TaskMaster also has semi-automatic Ball-in-court management. When Alice has set a 
ball-in-court on an item, any reply to the item will cause a special alert box notification to be 
S sent to Alice regarding whether TaskMaster should cancel the ball or change its status. For 
example, a special alert box notification might notify Alice that Dorothy has responded to an 
action ball with a message, show the subject of the message and provide Alice with options. 
Alice could dismiss the notice by clicking the Dismiss button, or open the message, by 
clicking the Open button and change the action ball setting from within the message if need 
10 be. Dorothy need not be a TaskMaster user for this to work, nor need Dorothy and Alice share 
any data that would not normally be exchanged by thek messaging systems. 
P If Dorothy were also TaskMaster user and an embodiment (described later) permitted 

> the sharing of items in thrasks and thus obligation tokens (balls), Dorothy could cancel the 
1 2 item from her own TaskMaster cUent by various means including clicking on the ball icon 
\n 15 itself, which would toggle it from red (my action) to blue (other's action) to white (no action). 

In this case, if Dorothy leaves the action ball red or changes it to be blue, the next message in 
»^ the same thrask from Dorothy to Alice or from Alice to Dorothy would cause the dialog box 
i= =^ i= to reappear showing the new state of the action. 

In TaskMaster, email is characterized as a work habitat not just a messaging 
S ^ 20 application. Thus file and link management is embedded in the email client. By this, it is 
meant that users can browse collections of email together with notes, other document types 
and links, which may or may not have been transmitted as email attachments. These 
information items may have been added to the collection by the user, who may move or copy 
items from their own hard drive or off another networked machine. These other items are 
25 viewed as first class citizens in the emaU viewer (rather than their presence being hinted at 
using some attachment icon with the item itself only properly accessible and identifiable by 
opening the message as is currently the case in most email tools). Thus, in Taskmaster it is 
possible for the user to see the type, identity and age of these other items in the messaging 
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system cUent's viewer, just as the user can with messages, without having to open messages, 
as is presently the case with attachments. 

In TaskMaster, each user-defined activity thread, and not the email message, is the 
primary unit of interest. TaskMaster provides a novel means of viewing email in terms of 
user-defined activities. The user decides what items should be represented as activities 
(which are termed thrasks as defined above). The user can create thrasks by manually 
including (e.g., dragging) a message or other item into a thrask viewing pane. The user can 
add fiirther messages or items to this same thrask. TaskMaster then begins to track any 
subsequent messages in the same threads as those akeady included in the thrask. An 
advanced embodiment of TaskMaster can track versions of the same document cieated and 
saved by a user on their own system, once they are added to a thiask in TaskMaster. 

In TaskMaster, email is organized not in terms of folders or threads, but in terms of a 
dynamicaUy filtered coUection or thrask (with the possibiHty of manual inclusion or exclusion 
of individual items). This means that, unlike threads, which use only message data to 
automatically compute a collection as in Microsoft's threaded browser, multiple threads may 
now relate to a single thrask, and other items such as documents, notes or random email 
messages may also be included manually in the thradc by a user of the system. 

Unlike folders and filters, thrasks do not require the user to set up a rule to have items 
be automatically added to a thrask. 

Mail messages and other items can be seen as representing or relating to tasks or sub- 
components of a task. Thus, any item such as a message, document, hyperlink, note and so on 
can stand for a task. This means that all items have deadline and reminder properties, which 
the user can leave unspecified or can set to some date. Further, even as task proxies, these 
elements remain displayed in the normal email client viewer. This contrasts with Outlook's 
tasks, which are functionally, and in terms of the user-interface, distinct from emaU messages, 
documents and so on. In Outiook, die tasks are organized in a separate collection. 

For every item witii a reminder or deadUne or both, including messages, documents, 
links, notes and so on, the user will receive a notification when the date for tiie reminder or 
deadline arrives. 
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Users will have practically continuous feedback about approaching deadlines and 
reminders associated with thrask collections (and possibly with individual items). The nearest 
approaching deadline and the nearest approaching reminder are represented at the top level of 
the user interface within the default content viewer, without the user having to open individual 
items to inspect them. In one implementation, this continuous notification is embodied as a 
bar for the nearest reminder or for the nearest deadline. In one embodiment of TaskMaster, 
these notification indicators change color along their length or grow in length as the specified 
date {q>proaches. 

Since all items are proxies for tasks, pending actions or obligations being waited upon 
are explicitly represented at the top level of the user interface of the email cUenL In one 
embodiment, obligations (of the user or of others) are represented at the item level and at the 
thrask level. At the item level, a mark (e.g., a red or blue baU) is associated with the item to 
show there is an obKgation (mine or someone else's) associated with it. At the thrask level, 
aggregation of obligations is represented as a group of marks (e.g., balls) associated with a 
thrask and these marks also distinguish user obligations from other's obligations. These 
obUgations must be user defined using an interface mechanism for changing the status of 
items within the thrask. The size of the group of marics grows as the obligations build up 
within the thrask by being associated one-by-one and one-to-one with items within that thrask. 
These differ from Outlook's Hags in that information about the nature of the action is visible 
at the top level of the interface (without having to open any item or dialog box). In another 
embodiment, the user is able to associate different colored or shq)ed balls or icons with 
specific people or actions. 

For any thrask, the user can select an option that shows the names of all the people 
whose names appear in the From: To: or Cc: lines of each message with a specified 
obUgation. These will be people to whom an action is owed or fix)m whom an action is 
expected. Common actions can then easily be associated with these names via a cascading 
menu or some other mechanism (as shown in FIG. 1 1). 

A thrask may be created with an incoming message automatically (for example, by the 
arrival of a message related to a preceding message in terms of message ID, sender or subject 
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line) or it may be restricted to an explicit user choice only. But, users can also create a thrask 
by adding an item that is not a message, such as a document or a link, to the system, fii such a 
case, no automatic filtering will take place until a message is added to the thrask, whereupon 
related incoming messages wiU be added automatically by the system. However, it is possible 
5 to automatically include new versions of the same document (or file) once they are included in 
TaskMaster, 

Items can also be suggested for thrasks based upon thek content even if they are not 
actually automatically filtered into a thrask. Indicators for low certainty and high certainty can 
be added to the suggestions. 

10 TaskMaster includes a deferral mechanism, which allows the user to see a timely 

appearance of upcoming task activity. When the user receives a message into or adds a new 
item to TaskMaster's thrask collection, if it is not already added to a thrask, it may become a 
thrask in its own right At any time after the creation of a thrask in any way, the user can 
select a system option to defer the thrask until a selected date, whereupon it disappears out of 

15 the normal thrask view of the system. In one implementation, if any new information item is 
acquired by the thrask before the specified date, the thrask will reappear and can be deferred 
once again. In another implementation, the user can opt not to see any incoming content item 
to the thrask until the specified date. In yet another implementation, the user can make a 
selection to see all deferred thrasks at any time. In still another implementation, users may 

20 similarly defer individual thrask items. 

TaskMaster clients can synchronize regularly with a shared workgroup client on a 
server to provide a shared view of a thrask. Users simply opt to share or un-share a thrask, or 
items in a thrask, by interacting with their TaskMaster client (an embodiment of a workgroup 
system is shown in FIG. 18). An augmented TaskMaster client and/or altemative group client 

25 could provide personal and public views onto the shared thrask information, including shared 
items, public obligations, deadlines, upcoming reminders and so on. 

It is central to this approach to note that, whether or not a central server is included to 
support shared views of thrasks and items in thrasks, through a combination of the 
mechanisms discussed above, users of TaskMaster receive support of the kind provided by a 
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workflow tool with no up-front model of any process being required, thus requiring no a priori 
system set-up for users. The combined effect of the mechanisms is to provide support for 
emergent and flexible workflow management. In other words, TaskMaster provides resources 
for users to create and manage workflows from an individual perspective by tracking 
S deadlines and obligations that are created by individual participants from the individual 
perspective on the fly. Any process model is thus simply inferred by users, based on the 
contextual information available in the informal and impromptu messages that are passed 
back-and-forth. 

Thus, this approach stands in contrast to the popular model of having a centralized 
10 workflow model keep track of a pre-specified set of obhgations and affords more flexible 
workgroup performance than traditional workflow approaches, 
i 3 A central notion of the TaskMaster-based workflow system is that workflow need not 

be defined by an explicit system model to be embodied in some system that controls access 
i;n and information flow according to a pre-defined plan or specification, or even a flexible, but 

i;;g 15 in some way pre-conceived plan or specification. It is already known that workflow processes 

ill 

can be emergent and highly flexible and can exist entirely in the heads of the participants or in 
Q the informal workplace culture rather than anywhere else. TaskMaster provides previously 
non-existent resources for managing ibis emergent workflow that are deeply embedded in an 
;; 4 email tool that people woidd typically use for general puipose messaging. The TaskMaster- 
! U 20 based workflow system does not require any shared, centralized resource for capturing any 
elements of the workflow (and does not require that everyone or even more than one person 
be using the TaskMaster resources for them to work; others can simply use a normal email 
tool). The workflow mans^ement emerges from the combination of many people separately 
managing their piece of the overall pattern and flow of information and obhgations using the 
25 information management resources. In particular these resources are: heterogeneous 
collections of items such as messages and documents that are automatically maintained and 
updated by the system but with flexible user customizations of creation, inclusion and 
exclusion; and metadata such as obhgations, deadlines, reminders and deferrals that can be 
associated with those items and the collections to which they belong. 
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However, in spite of the above, it is clear that the embodiment of the shared 
workgroup system of the present invention could also copy and keep track of certain public, 
but individually created, deadlines and obligations in a central location on a server (but this 
would still require no pre-specification of any process-related to-dos or dependencies). This 
5 would simply allow public actions to be publicly represented, by building a shared workflow 
lepresentation from the individual pieces. 

The following is one example of how a shared workgroup-enhanced TaskMaster 
implementation would work. 

A user may publish certain items for a workgroup identified by a unique email address 
10 and/or url, with members of the workgroup identified by their email address and a password 
(that can be distributed in email) or in some other manner that can be managed by the system, 
j «i A web or some other locally shared specialized client interface could be developed to 

manage access by workgroup members to a centralized server, 
iifi The system would then offer the user the option of saving a thrask in a public form 

i;g 15 such that any items added to the thrask will be accessible to all members of the workgroup. 
' - Thus all thrasks would have a "share" option available, and shared thrasks would be indicated 
Q through some mechanism, such as a shaied/not shared icon on each thrask in the standard 
i JL TaskMaster browser. 

;;!: In another embodiment, the system would only submit certain items from the user's 

j U 20 private version of the thrask to the pubKc version of the thrask (this could be determined by 
automatic processing criteria such as whether the item is related by message ID or subject line 
to a previously published item, or by explicit user action). This would minimize clutter that is 
only relevant to one person in the public view. Thus all individual items would have a 
'"share" option available and each item would have a shared/not shared icon. 
25 Actions (being defined purely as "mine" or " someone else's" in the single user case 

described earlier) in the workgroup version of the thrask could now be defined as being 
identified with a named user. Thus, the thrask list pane and the item list pane equivalents for 
a workgroup on a shared server would have to have a wider colunm identifying (possibly by 
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email address) who is responsible for the action items, rather than the thin column with the 
red and blue balls for the single user case. 

Rather than a fixed model of how the work is to be accomplished and in what order as 
in a traditional workflow model, this model allows for flexible sharing of information about 
5 who is responsible for what The context for the actions will appear in the public thrask 
(email and other items collection). Further messages to the thrask can provide updates as to 
whether someone has passed the work on to someone else with a message saying why. 

A history view of persons responsible for each item can be accessible by clicking on 
the action colunm. This makes people accountable to their workgroup colleagues for making 
10 changes to "who is currenfly responsible" for an item in the thrask. 

In a more sophisticated embodiment of the workflow system of the present invention, 
^ individual clients would able to poll the central server for updates to a thrask made by other 
fJ people. New content sent to ttie shared thrask could be downloaded to the local client 
i;fi automatically, keeping both versions in synchronization (though private versions would 

15 contain more content that is only relevant to the owner). 
!^ A further refinement would be to store only email messages on the central server and 

r J have documents that demand storage space always be downloaded to local users' machines to 
j T be accessible from thek local version of the thrask. 

SI; 

'f^ Individual users would be notified if someone else assigns a shared item on the server 

i y 20 that they have a copy of (see A, C or E in FIG 18) to them with an automatically generated 
updated copy of the item being sent to their personal version of the thrask. Another variation 
on the same theme would be to have, in the user's personal thrask view, actions changing 
fiom other to self or vice versa, appear different (changing fi-om red to blue or blue back to 
red). 

25 FIG. 18 shows an exemplary schematic of a workgroup-enhanced architecture for 

TaskMaster. Individual users' TaskMaster clients 1802, 1804 handle email exchanges and 
Outlook server-based archiving as described previously (thick dashed line) but these clients 
also update and are updated by a centralized thrask server 1806 with items that users opt to 
share by clicking on a share icon (indicated by letters A, C and E in bold). A group client 
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1808 (which may be implemented as an integrated part of the standard TaskMaster client) 
provides a view onto the shared thrask content. TaskMaster clients simply indicate that some 
items in a thrask are shared (indicated here as bold). 

Another way of implementing a workflow-enhanced version of TaskMaster would be 
5 to have a software module on the workgroup's Outlook Exchange or IMAP mail server that 
would provide an augmented, shared view onto the mail server content, in much the same way 
that TaskMaster provides an augmented view onto a user's Outlook client's content. 

The TaskMaster system may be implemented using software-programming 
instructions with conventional programming techniques to operate a computer-controlled 
10 system. A computer-controlled system as may be utilized to implement the TaskMaster 
system is illustrated in a simplified block diagram form with reference to FIG. 19. Referring 
to FIG. 19, the computer-based system is comprised of a plurality of components coupled via 
^ 2 a bus 1901. The bus 1901 may include a plurality of parallel buses (e.g., address, data and 
lu status buses) as well as a hierarchy of buses (e.g., a processor bus, a local bus and an I/O bus), 
•^fj 15 In any event, the computer system is further comprised of a processor 1902 for executing 
! instructions provided via bus 1901 from Intemal memory 1903 (note that the Internal memory 

i;3 1903 is typically a combination of Random Access or Read Only Memories). When in 
operation, program instructions for carrying out the various fimctional components of the 
;^ present invention are stored in intemal memory 1903. The processor 1902 and Intemal 
I U 20 memory 1903 may be discrete components or a single integrated device. The processor 1902 
and intemal memory 1903 comprise circuitry for performing the various processing functions 
described herein. Also coupled to the bus 1901 is external storage 1907. The external storage 
1907 is t^ically a high capacity storage media such as magnetic or optical disk storage. 

Also coupled to the bus 1901 is a display 1904 and a pointing device 1905. The 
25 pointing device 1905 may be a stylus, mouse, track-ball or other cursor control device. The 
network connection 1908 provides means for attaching to a network, e.g., a Local Area 
Network (LAN) card or modem card with appropriate software. Such access may be to the 
Internet or to local Intranets or both. Besides communication access, the network connection 
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1908 may be used to access various resources (i.e. servers) such as shared computing, storage 
or printing resources. 

Moreover, the computer controlled system upon which TaskMaster may be 
implemented includes the various forms of systems such as workstation computers, laptop 
computers Personal Digital Assistants, Notebook computers, mainframe systems, client-server 
systems and the like. 

While certain exemplary embodiments have been described in detail and shown in the 
accompanying drawings, it is to be understood that such embodiments are merely illustrative 
of and not restrictive on the broad invention. It will thus be recognized that various 
modifications, such as those mentioned above, may be made to the illustrated and other 
embodiments of the invention described above, without departing from the broad inventive 
scope thereof. For example, while the system described herein is described as a separate 
application apart from the e-mail application, it would be apparent to one of skill in the art 
that the present invention could be implemented as integrated with or additional provided to, 
an existing e-mail system. It will be understood, therefore, that the invention is not limited to 
the particular embodiments or arrangements disclosed, but is rather intended to cover any 
changes, adaptations or modifications which are within the scope and spirit of the invention as 
defined by the appended claims. 
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